Q: I have an application that make repeated calls to
\b PSscreenlist()
\b0 . If I run /NextDeveloper/Apps/ProcessMonitor, choose Display Postscript from the pop-up list, and watch the virtual memory usage, it continually increases. After a couple of hours or so, my system is on its knees thrashing away. How can I prevent this memory leakage?\
\
A: Many of the C-callable PostScript functions, including the aforementioned
\b PSscreenlist()
\b0 , require the use of compound objects within their wrap definition. Compound objects in PostScript are objects that are represented on the stack as a pointer to virtual memory where the data is actually stored. Arrays and dictionaries are both examples of compound objects.\
\
The appkit's wrap functions do pop compound objects off the stack before returning to the calling functions. However, the memory used to store compound objects is not freed when it is popped off the stack. Also, Display PostScript does not garbage-collect these stray memory locations (although it does other garbage collection). These two facts coupled together yield the growing program problem. The way to solve this problem is to strategically place
\b PSsave()
\b0 and
\b PSrestore()
\b0 commands in your code. Using
\b PSsave()
\b0 and
\b PSrestore()
\b0 in this manner is actually cheaper than a garbage-collection facility. This has the effect of returning the unused yet unfreed virtual memory back to the system. Remember that
\b PSsave()
\b0 and
\b PSrestore()
\b0 take some time to execute, so you should place them such that they get executed frequently enough to circumvent the memory leakage, but not so frequently as to cause performance problems.\
\fc0 \
QA753\
\
Valid for 1.0\
Valid for 2.0
\pard\tx533\tx1067\tx1601\tx2135\tx2668\tx3202\tx3736\tx4270\tx4803\tx5337\fc0 Entry: Mon Aug 26 16:08:21 1991 by NextAnswers Administrator [qap]
